Upgrading to Liferay DXP part #1 — portletIds

Upgrading to Liferay DXP part #1— portletIds

This blog post is part of the Liferay DXP upgrade series.

Are you working on an upgrade project from Liferay 6.2 to Liferay DXP?

Then, it is very likely, that you will have to deal with this specific use case:

How to replace old portletIds that use old name convention with new ones?

Photo by Patrick Perkins on Unsplash

The problem in detail

In your custom portlets, your former portletid was probably close to this:

public static final String OLD_PORTLET_ID = “1_WAR_notificationsportlet”;

Now, our goal will be to replace it with a new OSGI convention, that translates to:

public static final String NEW_PORTLET_ID = “com_liferay_notifications_web_portlet_NotificationsPortlet”;

At the end of the process, we would like that portlet preferences, and other portlet references use an updated portletid.

Liferay UpgradeProcess for the help

Liferay comes with a very neat solution to address this issue — it is called ‘UpgradeProcess’ and you can have multiple of them per module. We will refer to NotificationsWebUpgrade implementation as an example:

https://github.com/liferay/liferay-portal/blob/65059440dfaf2b8b365a20f99e83e4cdb15478aa/modules/apps/notifications/notifications-web/src/main/java/com/liferay/notifications/web/internal/upgrade/NotificationsWebUpgrade.java

Here, all portlet ids:

“1_WAR_notificationsportlet”,
“2_WAR_notificationsportlet”

will be replaced with

“com_liferay_notifications_web_portlet_NotificationsPortlet”

What is crucial for us, is that this process takes care of replacing the portletid references such as:

1. PortletId
2. ResourceAction
3. ResourcePermission
4. User Notification Delivery
5. User Notification Events
6. Instanceable PortletPreferences

For even more details, take a look here: https://github.com/liferay/liferay-portal/blob/65059440dfaf2b8b365a20f99e83e4cdb15478aa/portal-kernel/src/com/liferay/portal/kernel/upgrade/BaseUpgradePortletId.java#L386

Integrating UpgradeStepRegistrator for portletIds

Now, we will want to integrate this UpgradeStep into our custom portlet.

In our example, we will use a simple module created using the following template:

blade create -t mvc-portlet custom-portlet

Then, we will provide the implementation:

Deploying an upgrade module

Finally, let’s deploy our module and connect to the gogo shell to see newly registered upgrade process.

telnet localhost 11311

If you are not able to connect to gogo shell, you probably forgot to enable OSGi console in portal-ext.properties.

On your local machine, this would be the line to add:

# enable GoGo shell on localhost enabled
module.framework.properties.osgi.console=localhost:11311

Once you are connected, go and check the pending upgrade process to be performed.

g! upgrade:check

Our upgrade process should be on the list.

Whenever we are ready to update the references, we can proceed with:

g! upgrade:execute <module>

Now all portlet references will use the new portlet id.

You can easily incorporate this and many other Liferay upgrade features whenever performing an upgrade from 6.2.

In the next post, we will talk about working with module upgrades.

Upgrading to Liferay DXP part #2 — working with modules UpgradeSteps

Need to upgrade but not sure where to start? Reach out to us in Ableneo. We have rich experience with upgrading important projects to the latest versions of Liferay. Contact us at info@ableneo.com
👏Clap, 👂follow and 🤝join us, ableneo.com

Upgrading to Liferay DXP part #1 — portletIds was originally published in ableneo Technology on Medium, where people are continuing the conversation by highlighting and responding to this story.